home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000217-20000824 / 000234_news@columbia.edu _Thu Apr 27 05:06:48 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by fozimane.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id FAA23398
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Thu, 27 Apr 2000 05:06:47 -0400 (EDT)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id FAA09731
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 27 Apr 2000 05:06:46 -0400 (EDT)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id EAA16083
  10.     for kermit.misc@watsun.cc.columbia.edu; Thu, 27 Apr 2000 04:57:33 -0400 (EDT)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: Ishikawa <ishikawa@yk.rim.or.jp>
  13. Subject: Re: Parity incorrectly reported, and RTS/CTS problem on Solaris 7 for 
  14. Date: Thu, 27 Apr 2000 17:46:05 +0900
  15. Organization: RIMNET InterNetNews site
  16. Message-ID: <3907FE4D.8FCDB4E8@yk.rim.or.jp>
  17. To: kermit.misc@columbia.edu
  18.  
  19. Hello,
  20.  
  21. (Any volunteers yet?)
  22.  
  23. > : Here is my take on why this problem was not noticed before
  24. > : by the many kermit users on Sun boxes, and if my guess is correct,
  25. > : the problem didn't harm many people at all.
  26. > :
  27. > : - Hardware flow-control is only necessary when
  28. > :   CPU/OS is rather slow in comparison to the serial line speed.
  29. > :   Thanks to the deep hardware FIFO queue in serial controller, and
  30. > :   ever faster CPU...
  31. > :
  32. > Yes, that's true in one direction, but what about the other?
  33.  
  34. Forgot about the other direction!
  35.  
  36. >
  37. >  a. SVR4-style hardware flow control works in Solaris in one direction but
  38. >     not the other; or:
  39. >
  40. >  b. Kermit's dynamic packet sizing got around the errors, so nobody noticed
  41. >     them; or:
  42. >
  43. >  c. Nobody has been using > 57600 bps serial speeds; or:
  44. >
  45. >  d. Nobody is reporting problems.
  46. >
  47.  
  48. I would think that b, and c ("Bad cable" and shurrugedoff).
  49.  
  50. a is a little difficult, but anything goes with software.
  51.  
  52.  
  53. >
  54. > :   If my reading of the messages is correct, solaris up to 2.3 did
  55. > :   set RTS/CTS using ATT SysV semantics.
  56. > :   The first broken version of kermit for Solaris 2.4 for x86
  57. > :   didn't suffer much since the OS itself doesn't seem to have
  58. > :   support for 115200 bps at all.
  59. > :
  60. > So you have determined that SVR4 hwfc works in Solaris 2.3 and earlier?
  61. > I didn't see anything about this in yesterday's posting.
  62. >
  63.  
  64. Sorry to confuse you. I `assume'd that
  65. since nobody seemed to have reported problems on earlier systems
  66. (2.3 and older) [and assumed that you picked up SVR4 hwfc for a
  67. reason for solaris target] that SVR4 hwfc worked on such systems.
  68. Can't verify since these are indeed old  systems and
  69. I have no way to test such systems.
  70.  
  71. >: PS: if we can return the failure code (-1) from
  72. >: the att sysV semantics functions(s) to higher level
  73. >: funtions, at least we can tell the user that something is woring by
  74. >: printing some meaningful  messages.
  75. >:
  76.  
  77. > Yes, I can take of this.  It will be in the next release.  But it won't
  78. > affect Solaris > 2.3, since this code won't be used there any more, right?
  79.  
  80. Quite right. -DPOSIX_CRTSCTS would take care of this.
  81.  
  82. Happy Hacking,
  83.  
  84. Ishikawa
  85.  
  86.  
  87.